Web services, generally, refers to web-based applications that interact with other web-based applications in order to provide a desired service. For example, application software on a user's desktop computer (e.g., Microsoft Money) may send messages via the Internet to a stock quote server in order to retrieve current stock quotes for selected stocks. The application software may then display the retrieved information within the application for the user. Other examples of common web services include banking, currency converters, airplane flight schedule lookups, auction services and language translation services.
Integral to the widespread success of web services is the use of common data representations, common message formats and descriptions of operations for application-to-application communication over the Internet. Web services may be provided by a computer or any message-based computing service participating in any general-purpose computation, procedure or activity. Using these common data representations, formats and descriptions of operations, applications may use web services to interact with other applications to produce a common outcome for an activity, e.g., debiting an account in a banking transaction.
Multi-process coordination for transaction outcome for web services has been demonstrated to be of critical importance. Multi-process coordination, generally, refers to computer systems or web services in different environments communicating by exchange of messages using pre-defined protocols. It is desirable to achieve coordination of general purpose computations or activities between multiple web services or participants in order to achieve a coordinated outcome of distributed applications for a transaction. For example, in a banking transaction transferring money from one account to a second account, the results could be disastrous if the second account was credited with funds, but the first account was not correspondingly debited.
Transaction coordination was traditionally required to pass the ACID (Atomic, Consistent, Isolation and Durable) test. In particular, the transaction needs to be atomic such that the transaction is completed in its entirety or not at all. That is, if an atomic transaction will not be completed, it becomes completely undone. For example, if a transaction had been commenced but not completed and an event occurred that compromised the transaction, making completion of the transaction infeasible, the operations completed thus far could be undone such that the data could be “rolled back” to its original state.
The transaction also needs to be consistent. That is, given the same state, inputs, etc., the same result should occur. Next, each transaction needs to work in isolation such that one process does not interfere with the functioning of another process. In this way, different processes can be occurring in parallel with no single process adversely affecting the operation or results of any of the other processes. Finally, the transactions need to be durable so that the transactions, once completed, remain permanent even in the event of a system failure. That is, with durability, the result remains in the system even upon restart.
Web services systems may take many forms. In one type of system, web services or participants may be interconnected to each other to form a complete system that does not interact with other systems that are not connected, e.g., a local area network. Such a system has traditionally been referred to as a “glass house” system because the system may be self-contained without interference from external influences (such as external web services via a wide area network) without access authority. Thus, in the traditional glass house system, there may be many computers interconnected in a variety of ways to achieve an outcome within the privacy of the system. Systems may operate on a given computer, on several networked computers within the glass house or domain of trust, or the system may be extended to incorporate additional models of transactional behaviors.
Coordination of the computations carried out by multiple web services or participants in the form of an activity to achieve a joint outcome is desirable with the advent of computing outside the glass house, e.g., web services via the Internet, external to the self-contained system of interconnected web services or participants accessing the system. Coordination of activities with web services or participants between a glass house system (i.e., a self-contained system) with web services or participants outside of the glass house system, for example, across domains of trust or with individual endpoints (i.e., computers or web services) that may be located in distant locations as well as distant from each other may become problematic. Web services in different domains of trust, for example, must still perform as one enterprise but problems may arise due to the complex relationships between the participants, business latencies causing the execution of activities to take a long time, and user interactions. For example, web services providers may be located in different countries creating a distributed computing scenario. Regardless of the distributed nature of the system and the dissolution of the glass house, coordination of the outcome and agreement between the endpoints should be achieved.
Prior art systems utilize ACID resource managers operating on a given computer. Activity or changes in a system or resource is noted by resource managers enabling physically committing or rolling back changes in the system. Groups of ACID resource managers may operate on several networked computers but typically within one domain of trust. Durable queue managers have been used to extend the use of transactions to asynchronous services operating on different domains of trust. Transactional behavior is provided at each of the end points with message transmission between the end points.
However, in prior systems, participants or web services coordinate an activity with other web services by accessing predetermined protocols. The predetermined protocols determine the behavior and the transactional outcome of activities are determined by transactional behavior that is provided at each web service or endpoint in the system.
For example, in a prior art file system, the activity may be a data update. Participants or web services might not prescribe the manner of message exchange and might not orchestrate the communication of messages (i.e., protocols) to coordinate the activity between different participants. Behavior or protocols are instead provided at each of the participants or web services themselves. However, each of the participants or web services might be unable to optimally coordinate the outcome of a joint activity. In particular, for a file service and a web service to jointly perform a data update according to a behavior described by a protocol, there is no current manner to establish and control this coordination in an open-ended fashion.
Likewise, in a prior art credit/debit system, a participant or web service may be a user attempting to perform a financial transaction such as making a withdrawal from a financial institution. The activity (i.e., funds withdrawal) needs to be coordinated between the participants in the withdrawal such that a coordinated transactional outcome is attained, i.e., the withdrawal is successfully completed. However, in the prior art credit/debit systems, the participants are provided with predetermined transactional behavior at each of the endpoints with message transmission between the endpoints. Although geographically distributed services may operate in this manner, coordinating the outcome of a joint activity (i.e., withdrawal from an account and deposit in another one) is problematic as the protocols are pre-specified by a coordinator and not specified by the participants themselves. This results in diminished flexibility in the system and difficulty in coordinating the outcome of a joint activity in an extensible manner.
Thus, there is a lack of flexibility in coordinating activity between web services in an extensible manner. For example, a new web service that wants to participate in an activity with another web service would need to conform to the provided transactional behavior to coordinate activities with the other web service. This problem is magnified when web services or participants operate on several domains of trust. Notably, the prior art systems lack the proper infrastructure to provide for handling loosely-coupled web services to coordinate the outcome of an activity. Because agreements are only achieved through a prescribed fixed set of protocols and the participants or web services themselves do not orchestrate the protocols and messages themselves to coordinate the activity between the web services, web services not supporting a particular protocol may not effectively coordinate activities with other web services.
Thus there is a need in the art for a method and apparatus for allowing the coordination of activities by multiple web services such that new web services may dynamically obtain or utilize proper protocol information and participate in an activity with another web service. By accomplishing coordination of transactional activity in an extensible manner, additional web services may more efficiently join in an activity with another web service according to protocols specified dynamically by the participants or web services themselves.